数据 | 核心生产要素[0]数据架构[02]数据仓库架构

数仓架构与数据建模概述

Catalogue
  1. 一、背景（why）
  2. 二、目标
    1. 2.1 数仓架构的目标
    2. 2.2 数据建模的目标
  3. 三、概要设计（what）
    1. 3.1 关键问题
    2. 3.2 数仓架构蓝图
    3. 3.3 数据建模概要
      1. 1. 域表定义
      2. 2. 关联规则
  4. 四、详细设计（how）
    1. 4.1 数仓架构分层
      1. 4.1.1 经典四层架构
      2. 4.1.2 阿里五层架构
      3. 4.1.3 轻量三层架构
      4. 4.1.4 核心架构模式
    2. 4.2 架构核心概念
      1. 4.2.1 基础定义
      2. 4.2.2 核心流程
      3. 4.2.3 数据建模
      4. 4.2.3 分层核心
    3. 4.3 数据建模
      1. 4.3.1 核心建模方法论
      2. 4.3.2 主流建模模式
      3. 4.3.3 建模落地全流程
      4. 4.3.4 建模的核心概念
      5. 4.3.5 建模工具
    4. 4.4 湖仓一体演进

随着企业数字化转型深入，数据呈现 “多源异构、规模激增、价值密度不均” 的特征，如何才能让企业零散的数据变得更有价值，数据仓库和数据建模的概念应运而生。

企业级数据仓库理论是在90年代提出，核心思想是分离业务处理与分析处理系统，是一种 “面向主题、集成化” 的架构模式，同时期还提出数据集市概念，解决了企业级数仓实施复杂的问题。21 世纪后，随着大数据技术兴起，数仓架构与 Hadoop、OLAP 等工具深度融合，形成了支持海量数据处理的现代化架构体系。其核心使命是通过系统化的架构设计，将零散数据转化为结构化、高价值的决策资产，支撑企业数据驱动转型。

一、背景（why）

问题1：（数据孤岛难使用）数据分散存储于不同系统，形成 “信息孤岛”，难以实现跨业务联动分析；
问题2：（非标准化）原始数据存在冗余、缺失、格式不一致等问题，直接影响分析结果可靠性
问题3：（效率低成本高）业务部门需频繁重复计算，导致数据处理效率低下、资源浪费严重。

传统 “零散存储、无序关联” 的数据管理方式已无法满足业务（数智化、精细化、多样化..）需求。

数据(核心价值)是企业的核心竞争力、数字化转型的关键、未来创新的基础，具体包括：

  • BI(商业智能)数据驱动高效决策、AI(企业数智化)
  • 降本增效（生产优化、供应链优化）、风险控制（金融、制造业）、提升质量（质量检测、预测性维护）
  • 客户管理（CRM、精准营销）、业务在线化（数字化转型的基础）

数据仓库解决了将零散数据转化为结构化、高价值的决策资产，支撑企业数据驱动转型的问题。
数仓架构的本质是数据流转与存储的顶层设计，明确数据从采集（ODS 层）到应用（ADS 层）的分层逻辑、各层功能边界、技术选型规范，相当于为数据构建了 “标准化的流转通道”，是数仓的 “骨架”—— 决定了数仓的扩展性、可维护性、处理效率上限。

数据建模作为数仓架构落地的核心(手段)，是数据组织与关联的具体实现。
通过定义主题域、事实表、维度表、表间关联规则（如星型 / 雪花模式），将零散数据转化为结构化、可关联的 “数据模型”，相当于为 “骨架” 填充 “血肉”—— 决定了数据能否被高效查询、多维度分析，直接支撑业务决策需求。

二、目标

关键词：（数仓架构）分层约束、边界定义、技术支撑、数据整合、高效分析

数仓架构的 数据整合、高效分析，以及可维护性 依赖建模和建模的规范实现。

  • 数据整合：通过维度表统一（如 DIM 层的用户维度表关联各业务系统用户数据）、事实表关联维度表，打破 “信息孤岛”，实现跨业务域数据关联，落地架构的 “集成化” 目标；
  • 高效分析：通过星型模式减少表关联次数、宽表建模减少查询开销、DWS 层预聚合建模降低重复计算，落地架构的 “提升处理效率” 目标。
  • 可维护性：建模定义的字段命名规则、表结构设计规范（如事实表包含时间戳字段、维度表包含主键字段），让架构各层数据 “可理解、可复用”，当源系统变更时，仅需调整对应模型逻辑，无需重构架构。

需将零散数据转化为 “结构化、可分析、可关联” 的资产。数据建模作为数据组织的核心手段，成为支撑报表分析、智能推荐、风险控制等场景的基础。​

2.1 数仓架构的目标

数仓架构设计的本质是在 “数据规模、处理效率、业务灵活性” 之间寻找平衡，核心目标可概括为五大方向：

  • 数据整合与标准化：打破多源系统数据壁垒，通过统一建模消除数据歧义与冗余，实现跨业务域数据的一致性关联
  • 提升数据质量与可靠性：通过分层清洗、校验机制，去除脏数据、补充缺失值、统一数据格式，为分析决策提供 “干净、可用” 的数据基础。
  • 优化数据处理效率：通过预聚合、计算复用等设计，减少重复计算开销，以 “空间换时间” 提升查询响应速度，满足报表、即席分析等场景的实时性需求。
  • 增强系统可维护性与扩展性：采用模块化分层设计，明确各层功能边界，当源系统升级或新增业务时，仅需调整对应层级逻辑，避免架构重构，适配企业业务动态发展。
  • 支撑全链路数据治理：实现数据血缘可追溯、权责可管控，当数据异常时能快速定位问题源头，同时满足合规要求（如数据脱敏、权限隔离）。

2.2 数据建模的目标

数据建模的核心目标。建模的本质是 “让数据更有价值”，核心目标围绕 “规范数据组织、提升分析效率、支撑业务决策” 展开，具体可分为五大方向：

  • 数据标准化与一致性：通过统一字段定义、数据格式、统计口径，消除数据歧义，确保不同部门使用同一套数据语言。
  • 数据关联与整合：打破数据孤岛，通过定义表间关联规则（如事实表与维度表的主键关联），实现跨业务域数据联动（
  • 提升数据查询与分析效率：通过合理的表结构设计（如宽表、预聚合表）、索引优化、关联逻辑简化（如星型模式减少表关联次数），降低查询开销，让业务人员快速获取分析结果（如报表查询响应时间从分钟级降至秒级）。
  • 增强数据可维护性与扩展性：采用模块化、分层建模思路，明确各模型的职责边界，当业务变更（如新增 “会员等级” 字段）或源系统升级时，仅需调整对应模型，无需重构整体数据体系，适配业务动态发展。
  • 支撑数据治理与合规：通过建模明确数据来源、流转路径（数据血缘），实现数据权责管控（如敏感字段脱敏、权限隔离），满足合规要求（如 GDPR、个人信息保护法），同时便于数据问题定位（如某指标异常时，可通过模型追溯至原始数据）。

三、概要设计（what）

3.1 关键问题

3.2 数仓架构蓝图

以上架构蓝图，如需“落地、规模化运营”，还需要 工程闭环和中台完成态

  1. 每一层数据到底落在哪？ 谁负责查询、谁负责服务
  2. 数据服务层都有哪些服务？指标服务、标签服务、特征服务。API、SLA、服务的定义和治理
  3. Lambda / Kappa 是“理念块”，哪层用哪个？是否共存？ 「共存，局部选择使用」
  4. 治理体系：什么时候采集元数据？在哪做质量校验？权限控制到哪一层？「缺乏工程抓手」
  5. Lambda的架构 必须实时和离线存在吗？对实时的结果需要离线校验和回补吗？
  6. 存储层定义：分离线存储、实时（分析、明细）存储、服务型存储「分层和模型与存储层是如何对应的？」

3.3 数据建模概要

作为数仓架构落地的核心手段和血肉，数据建模解决了数据如何组织和关联的问题。

通过定义主题域、事实表、维度表、表间关联规则（如星型 / 雪花模式），将零散数据转化为结构化、可关联的 “数据模型”，相当于为 “骨架” 填充 “血肉”—— 决定了数据能否被高效查询、多维度分析，直接支撑业务决策需求。

1. 域表定义

2. 关联规则

四、详细设计（how）

4.1 数仓架构分层

4.1.1 经典四层架构

适用于大多数中大型企业，通过四级分层实现数据 “采集 - 清洗 - 聚合 - 应用” 的全流程规范化管理，各层功能边界清晰：​
ODS 层（操作数据存储层）：数仓的 “数据入口”，直接对接业务数据源，以原始格式存储订单、日志等数据，保留数据原貌与元信息（如来源系统、采集时间），支持数据追溯，存储周期较短（按天 / 周归档）。​
DWD 层（明细数据层）：核心 “数据清洗转换层”，通过去重、补全缺失值、统一字段命名与类型等操作处理原始数据，同时关联用户、商品等维度信息形成宽表，输出干净的明细数据，是数据复用的核心层。​
DWS 层（汇总数据层）：面向主题的 “聚合计算层”，按时间（日 / 月 / 年）、地域、产品等维度对 DWD 层数据轻度汇总（如月度各区域销售额），按业务主题域（用户、交易、营销）划分模型，减少下游重复计算。​
ADS 层（应用数据层）：直接服务业务的 “结果输出层”，基于 DWS 层数据定制化生成报表、看板、API 接口数据，支持 BI 工具、推荐系统等前端应用，部分场景需进行数据脱敏处理。

4.1.2 阿里五层架构

（大型企业增强方案）

在经典四层基础上新增两层，强化复杂业务场景的数据治理能力：​
新增维度层（DIM 层）：统一管理企业级维度数据（如用户、商品、组织架构），避免维度冗余与不一致，提升数据关联效率；​
新增中间层（DWM 层）：介于 DWD 与 DWS 之间的轻度汇总层，进一步平衡明细数据保留与计算效率，适配超大型企业的多维度分析需求。

4.1.3 轻量三层架构

简化为 “ODS 层→DW 层→DM 层”：ODS 层负责数据采集，DW 层整合清洗与轻度汇总，DM 层（数据集市）直接对接部门级应用需求，特点是部署快、成本低，适合业务场景单一的小型企业。

4.1.4 核心架构模式

星型模式：最常用的建模模式，由一个大型事实表（存储业务指标，如销售额）和多个小型维度表（存储描述信息，如时间、地域）组成，维度表通过主键直接关联事实表，结构简单、查询高效。​
雪花模式：星型模式的扩展，维度表进一步拆分为多层子维度表（如地域维度拆分为国家 - 省份 - 城市），数据冗余更低，但查询时需多表关联，适用于对数据规范性要求极高的场景。

4.2 架构核心概念

4.2.1 基础定义

数据仓库（Data Warehouse, DW）：面向主题的、集成的、非易失的、随时间变化的数据集合，核心作用是支持管理决策，区别于业务数据库的 “事务处理” 定位。​
数据集市（Data Mart）：数仓的子集，针对特定业务部门或主题（如财务、营销）构建的局部数据集合，数据来源于企业级数仓，直接服务于部门级分析需求。​
元数据（Metadata）：描述数据的数据，包括数据来源、转换规则、字段含义、权限信息等，相当于数仓的 “数据字典”，支撑数据血缘追踪与自动化处理。

4.2.2 核心流程

ETL（Extract, Transform, Load）：数据从源系统到数仓的核心流程，包括抽取（Extract，从多源系统采集数据）、转换（Transform，清洗、标准化、关联处理）、加载（Load，将处理后的数据写入数仓对应层级）三大环节。​
OLAP（Online Analytical Processing）：联机分析处理技术，支持对多维数据进行切片、切块、钻取等操作，实现多角度、多层次的深度分析，是数仓架构的核心分析能力支撑。

4.2.3 数据建模

主题域：按业务核心领域划分的数据集合（如用户主题、交易主题、商品主题），是数仓数据组织的核心逻辑单元。​
事实表：存储业务过程中的量化数据（如订单金额、销售量），包含与维度表关联的主键和业务指标字段，是分析的核心数据载体。​
维度表：存储描述性信息（如用户年龄、商品类别、时间周期），用于对事实表数据进行分类统计与分析，是实现多维分析的基础。​

4.2.3 分层核心

数据血缘：描述数据在各层级间的流转关系（如 ADS 层报表数据来源于 DWS 层哪个汇总表），支持问题定位与数据追溯；​
宽表：整合多个数据源的相关字段形成的大表（如 DWD 层的用户订单宽表，包含用户信息、商品信息、支付信息），减少查询时的表关联操作，提升效率；​
数据脱敏：对敏感数据（如手机号、身份证号）进行加密、掩码处理，在保障数据可用性的同时满足合规要求，常见于 ADS 层数据输出场景。

4.3 数据建模

数据建模需结合企业业务复杂度、数据规模、分析场景选择合适方案，主流方案可分为 “建模方法论”“建模模式”“落地流程” 三类，形成完整的实施体系：​

4.3.1 核心建模方法论

方法论决定建模的整体思路，主流分为两类，适用于不同企业规模：​
Inmon 方法论（企业级数据仓库建模）​
核心思想：“自上而下” 构建，先建立企业级数据仓库（EDW），再基于 EDW 拆分部门级数据集市；强调数据的统一性、集成性，先整合所有源数据，再按主题域建模。​
优势：数据一致性强、架构稳定，适合大型企业（如集团型公司），支撑跨部门、长期的数据分析需求；​
劣势：实施周期长、成本高，对业务理解深度要求高。​
Kimball 方法论（数据集市建模）​
核心思想：“自下而上” 构建，先围绕单个业务主题（如销售、营销）构建独立数据集市，再逐步整合为企业级数据仓库；强调快速交付、业务导向，优先满足部门级紧急分析需求。​
优势：实施周期短、见效快，成本低，适合中小型企业或业务场景单一的部门；​
劣势：前期数据一致性较弱，后期整合难度可能增加。

4.3.2 主流建模模式

建模模式定义数据的组织形式，是方法论的具体落地手段，核心分为三类：​

「星型模式（应用最广泛）」

结构：由 1 个核心事实表（存储量化指标，如订单金额、销售量）和多个维度表（存储描述性信息，如时间、地域、用户、商品）组成，维度表通过主键直接与事实表关联，结构类似 “星星”。​
特点：表结构简单、关联逻辑清晰，查询时无需复杂的多表嵌套关联，分析效率高，适合大多数业务场景（如报表统计、即席分析）。​
示例：“订单事实表”（订单 ID、用户 ID、商品 ID、订单金额、下单时间）关联 “用户维度表”（用户 ID、姓名、会员等级）、“商品维度表”（商品 ID、类别、价格）、“时间维度表”（日期、年、月、周）。

「雪花模式（星型模式的扩展）」

结构：在星型模式基础上，将维度表进一步拆分为多层子维度表，形成 “雪花状” 结构。​
特点：数据冗余度低（如 “地域维度表” 拆分为 “国家表→省份表→城市表”），数据规范性更强；但查询时需多层关联，效率略低于星型模式，适合对数据冗余敏感、合规要求极高的场景（如金融行业风控数据建模）。

「宽表模式（高并发查询场景）」

结构：将多个相关表的字段整合到一张表中，包含大量维度字段和指标字段，减少表间关联。​
特点：查询效率极高（无需关联多张表），适合高并发、低延迟的分析场景（如实时看板、API 接口查询）；但数据冗余度较高，维护成本略高，常见于 DWD 层明细数据建模。

4.3.3 建模落地全流程

数据建模不是一次性设计，而是 “设计→落地→优化” 的闭环流程，核心步骤如下

业务调研与需求分析：明确建模目标（如支撑销售分析、风控决策），梳理业务流程（如订单从创建到支付的全流程），确定核心指标（如销售额、转化率）和维度（如时间、地域、渠道）。​
数据调研与梳理：盘点源数据（如业务数据库表、日志文件），明确数据类型、字段含义、数据质量（如缺失率、重复率），梳理数据流转路径。​
主题域划分：按业务核心领域划分主题域（如用户主题域、交易主题域、营销主题域、商品主题域），明确各主题域的边界与关联关系。​
概念模型设计：抽象核心业务实体（如用户、订单、商品）及实体间的关联关系（如 “用户 - 下单 - 订单”“订单 - 包含 - 商品”），形成 ER 图（实体关系图），不涉及具体技术实现。​
逻辑模型设计：将概念模型转化为具体的表结构设计，明确字段名称、数据类型、主键、外键、约束条件（如非空、唯一），定义指标计算规则（如 “订单金额 = 商品单价 × 数量 - 优惠金额”）。​
物理模型设计：结合技术选型（如数据库类型、数仓架构分层），将逻辑模型落地为物理表，设计分区策略（如按时间分区）、索引、存储格式（如 Parquet、ORC），优化查询性能。​
模型评审与落地：组织业务人员、技术人员评审模型（如字段定义是否合理、关联逻辑是否准确），通过建模工具生成 SQL 脚本，创建物理表并导入数据。​
模型监控与优化：监控模型运行状态（如查询效率、数据质量），根据业务变更（如新增业务场景）或数据问题（如指标异常），迭代优化模型结构（如新增字段、调整关联逻辑）。

4.3.4 建模的核心概念

「核心指标相关概念」
维度：分析数据的 “角度”，如时间、地域、用户等级，用于对指标进行分类、筛选（如 “2024 年 3 月北京地区 VIP 用户的销售额”）。​
指标：分析的 “度量值”，分为两类：​
原子指标：最基础的指标，不可拆分（如订单金额、订单数量）；​
派生指标：基于原子指标计算得到的指标（如客单价 = 订单金额 / 订单数量、转化率 = 成交订单数 / 访问次数）。​
统计口径：指标的计算规则与范围（如 “活跃用户” 的口径的是 “当日登录且产生行为的用户”，需明确界定 “行为” 的定义，如浏览、下单、支付），是确保数据一致性的核心。

「核心实体与表类型」
事实表、维度表、主题域

「建模关键术语」

  • ER 图（实体关系图）：用于描述实体（如用户、订单）、属性（如用户 ID、订单金额）及实体间关联关系（如一对一、一对多、多对多）的可视化图表，是建模设计的核心工具。​
  • 主键（Primary Key, PK）：用于唯一标识表中每条记录的字段（如用户 ID、订单 ID），确保数据唯一性，是表间关联的核心依据。​
  • 外键（Foreign Key, FK）：用于关联其他表的字段，指向另一张表的主键（如订单表中的用户 ID 是用户表的外键），实现表间数据联动。​
  • 数据血缘：描述数据从源系统到目标模型的流转路径（如 “ADS 层销售报表数据→来源于 DWS 层交易汇总表→来源于 DWD 层订单宽表→来源于 ODS 层订单原始表”），支撑数据追溯与问题定位。​
  • 宽表：整合多个相关表的字段形成的大表，包含大量维度字段和指标字段，减少表间关联，提升查询效率（如 DWD 层的 “用户订单宽表”，包含用户信息、订单信息、商品信息、支付信息）。​
  • 分区表：按特定字段（如时间、地域）将物理表拆分为多个分区，查询时仅扫描目标分区，减少数据扫描量，提升查询效率（如按 “下单日期” 分区的订单表）。

4.3.5 建模工具

建模工具成熟（如 PowerDesigner、Erwin、DBeaver），支持可视化设计、自动生成 SQL、数据血缘追踪，降低建模门槛；​

4.4 湖仓一体演进